CC @psumbera @rorth @koachan @jrtc27 @andreas-gaisler

I'm not very familiar with Rust, but from what I can tell it looks okay.

Also, a word on this:

My understanding is that (some) use of the v9 feature may eventually be replaced by the v8plus feature in LLVM 20 (llvm/llvm-project@aca971d), but there is no other good way in the current LLVM 19.

v8plus is a purely ABI flag, intended to signal that the G and O registers are 64-bit. It is separated in LLVM because we want to be GCC-compatible and so need to cater to a particular usecase in which V9 instructions are desired, but all registers are to be kept 32-bit (effectively banning instructions like CASXA which needs 64-bit registers to operate).
If Rust doesn't want to do this, it could always set (or delete) v9 and v8plus together...

v8plus is a purely ABI flag, intended to signal that the G and O registers are 64-bit. It is separated in LLVM because we want to be GCC-compatible and so need to cater to a particular usecase in which V9 instructions are desired, but all registers are to be kept 32-bit (effectively banning instructions like CASXA which needs 64-bit registers to operate). If Rust doesn't want to do this, it could always set (or delete) v9 and v8plus together...

Thanks for the clarification. I think separating v8plus from v9 is the correct behavior (eventually) for Rust as well, as we do not want the ABI to be changed by -C target-cpu (-mtune).

However, we are using LLVM 19 which ties v9 and v8plus together and need a way to fix a bug in rustc that incorrectly always uses EM_SPARC32PLUS (#130172).

In #131222 we are trying to adopt the same approach as in LLVM 19, but actually adding the v8plus feature and mapping them to the v9 feature in LLVM 19 may be a better way here. (The implementation of it is in 0849356 and even if we merge the LLVM 19's approach, we will probably need it when updating to LLVM 20.)

☔ The latest upstream changes (presumably #129884) made this pull request unmergeable. Please resolve the merge conflicts.